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Description 

HANDLING OF AN UNRECOVERABLE 
ERROR ON A DEDICATED CHANNEL 

Cross Reference To Related Applications 

[0001] This application claims the benefit of U.S. Provisional Ap- 
plication No. 60/319,465, filed 08/13/2002, and included 

herein by reference. 
Background of Invention 

[0002] i. Field of the Invention 

[0003] jhe present invention relates to a wireless communica- 
tions device. More particularly, the present invention re- 
lates to discriminating between the handling of a layer 2 
unrecoverable error and a layer 1 radio link failure. 

[0004] 2. Description of the Prior Art 

[0005] jhe 3 rd Generation Partnership Project (3GPP) specifica- 
tions 3GPP TS 25.331 V3.11.0 (2002-06) "Radio Resource 
Control (RRC) Protocol Specification" and 3GPPTS 25.322 
V3.11.0 (2002-06) "Radio Link Control (RLC) protocol 



specification", both of which are included herein by refer- 
ence, provide technical description of a Universal Mobile 
Telecommunications System (UMTS). The UMTS discloses 
a device (typically a mobile device), termed user equip- 
ment (UE), in wireless communications with one or more 
base stations. These base stations (so-called Node Bs) 
with Radio Network Controllers (RNCs) are collectively 
termed the UMTS Terrestrial Radio Access Network, or 
UTRAN for short. 
[0006] please refer to Fig.l. Fig.l is a simple block diagram of a 
3GPP wireless communications network 10. The wireless 
communications network 10 comprises a plurality of radio 
network subsystems (RNSs) 20 in communications with a 
core network (CN) 30. The CN 30 includes a packet switch 
(PS) domain 30p and a circuit switch (CS) domain 30c. The 
plurality of RNSs 20 form a UTRAN 20u. Each RNS 20 
comprises one RNC 22 that is in communications with a 
plurality of Node Bs 24. Each Node B 24 is a transceiver, 
which is adapted to send and receive wireless signals, and 
which defines a cell region. A number of cells (i.e., a num- 
ber of Node Bs 24) taken together defines a UTRAN Regis- 
tration Area (URA). In particular, the wireless communica- 
tions network 10 assigns a UE 40 to a particular RNS 20, 



which is then termed the serving RNS (SRNS) 20s of the UE 
40. Data destined for the UE 40 is sent by the CN 30 (or 
UTRAN 20u) to the SRNS 20s. It is convenient to think of 
this data as being sent in the form of one or more packets 
that have a specific data structure, and which travel along 
one of a plurality of radio bearers (RBs) 28, 48. An RB 48 
established on the UE 40 will have a corresponding RB 28 
established on the UE SRNS 20s. The RBs are numbered 
consecutively, from RB0 to RBn. Typically, RB0 to RB4 are 
dedicated signaling RBs (SRBs), which are used for passing 
protocol signals between the UTRAN 20u and the UE 40, 
and will be described in some more detail below. RBs 28, 
48 greater than four (i.e., RB5, RB6, etc.) are typically used 
to carry user data. The RNC 22 utilizes a Node B 24, which 
may be assigned to the UE 40 by way of a Cell Update 
procedure, to transmit data to, and receive data from, the 
UE 40. The Cell Update procedure is initiated by the UE 40 
to change a cell as defined by a Node B 24. Selection of a 
new cell region will depend, for example, upon the loca- 
tion of the UE 40 within the domain of the SRNS 20s. The 
UE 40 sends data to the wireless communications network 
10, which is then picked up by the SRNS 20s and for- 
warded to the CN 30. Occasionally, the UE 40 may move 



close to the domain of another RNS 20, which is termed a 
drift RNS (DRNS) 20d. A Node B 24 of the DRNS 20d may 
pick up the signal transmitted by the UE 40. The RNC 22 
of the DRNS 20d forwards the received signal to the SRNS 
20s. The SRNS 20s uses this forwarded signal from the 
DRNS 20d, plus the corresponding signals from its own 
Node Bs 24 to generate a combined signal that is then de- 
coded and finally processed into packet data. The SRNS 
20s then forwards the received data to the CN 30. Conse- 
quently, all communications between the UE 40 and the 
CN 30 must pass through the SRNS 20s. 
[0007] please refer to Fig. 2 in conjunction with Fig.l. Fig. 2 is a 
simple block diagram of a UMTS radio interface protocol 
architecture, as used by the communications network 10. 
Communications between the UE 40 and the UTRAN 20u 
is effected through a multi-layered communications pro- 
tocol that includes a layer 1, a layer 2 and a layer 3, which 
together provide transport for a signaling plane (C-plane) 
92 and a user plane (U-plane) 94. Layer 1 is the physical 
layer 60, and in the UTRAN 20u is responsible for com- 
bining signals received from the DRNS 20d and SRNS 20s. 
Layer 2 includes a packet data convergence protocol 
(PDCP) layer 70, a Radio Link Control (RLC) layer 72, and a 



Medium Access Control (MAC) layer 74. Layer 3 includes a 
Radio Resource Control (RRC) layer 80. The U-plane 94 
handles user data transport between the UE 40 and the 
UTRAN 20u (RBs 28, 48 from five and upwards), whereas 
the C-plane 92 handles transport for signaling data be- 
tween the UE 40 and the UTRAN 20u (RBs 28, 48 from 
zero to four). The RRC 80 sets up and configures all RBs 
28, 48 between the UTRAN 20u and the UE 40. The PDCP 
layer 22 provides header compression for Service Data 
Units (SDUs) received from the U-plane 94. The RLC layer 
72 provides segmentation of PDCP 70 SDUs and RRC 80 
SDUs into RLC protocol data units (PDUs). The RLC layer 
72 is composed of one or more RLC entities 76. Each RLC 
entity 76 is individually associated with an RB 28, 48. For 
an RB 28 on the UTRAN 20u side, there exists an RLC en- 
tity 76 dedicated solely to that RB 28. For the same RB 48 
on the UE 40 side, there similarly exists a corresponding 
RLC entity 76. These two corresponding RLC entities 76 
for the same RB 28, 48 are termed "RLC peer entities". 
Under acknowledged mode (AM) transfers, the RLC layer 
72 can provide upper layers (such as the PDCP layer 70 or 
the RRC layer 80) with a confirmation that RLC PDUs have 
been successfully transmitted and received between the 



RLC peer entities 76 on the UTRAN 20u and the UE 40. 
The MAC layer 74 provides scheduling and multiplexing of 
RLC PDUs onto the transport channel, interfacing with the 
physical layer 60. 
[0008] please refer to Fig. 3 with reference to Fig.l and Fig. 2. 

Fig. 3 is a state diagram of the RRC layer 80. The RRC layer 
80 has two primary states: an idle mode 81 and a UTRA 
RRC Connected Mode 86. While in idle mode, the RRC 
layer 80 has no lines of communication open with its peer 
RRC layer 80. That is, there are no available SRBs 28, 48 
that enable communications between peer entity RRC lay- 
ers 80, except for RB0, which is a common channel avail- 
able to all UEs 40 in the UTRAN 20u. Utilizing the UE 40 as 
an example platform, once the RRC layer 80 of the UE 40 
establishes a connection (i.e., SRBs 28, 48 from one to 
four) with its peer RRC layer 80 on the UTRAN 20u, the 
RRC layer 80 of the UE 40 switches into the UTRA RRC 
Connected Mode 86. This connection is typically initiated 
along RB0, which is a shared channel. Internally, the UTRA 
RRC Connected Mode 86 has four unique states: 
CELL.DCH 82, CELL.FACH 83, CELL.PCH 84 and URA.PCH 
85. The CELL_DCH state 82 is characterized in that a ded- 
icated channel is allocated to the UE 40 for uplink (UE 40 



to UTRAN 20u) and downlink (UTRAN 20u to UE 40) com- 
munications. The CELL_FACH state 83 is characterized in 
that no dedicated channel is allocated to the UE 40, but 
instead the UE 40 is assigned a default common or shared 
transport channel for uplink. The CELL_PCH state 84 is 
characterized in that no dedicated physical channel is al- 
located to the UE 40, no uplink activity is possible for the 
UE 40, and the position of the UE 40 is known by the 
UTRAN 20u on a cell level (i.e., a node B basis 24). The 
URA_PCH state 85 is characterized in that no dedicated 
physical channel is allocated to the UE 40, no uplink activ- 
ity is possible for the UE 40, and the position of the UE 40 
is known by the UTRAN 20u on a URA basis. 
[0009] a number of reconfiguration procedures are available to 
the RRC layer 80 to setup and configure RBs 28, 48. These 
procedures involve the UTRAN 20u sending a specific 
message to the UE 40 along an RB 28, 48 in the C-plane 
92, and the UE 40 responding in turn with a correspond- 
ing message, also along the C-plane 92. Typically, the 
message is sent along RB2. The messages include Radio 
Bearer Setup, Radio Bearer Reconfiguration, Radio Bearer 
Release, Transport Channel Reconfiguration and Physical 
Channel Reconfiguration, as indicated in the above-in- 



dicated 3GPP specification TS 25.331, subclause 8.2.2. For 
each of these reconfiguration messages, the UE 40 has a 
corresponding "Complete" or "Failure" response message 
indicating success or failure of the procedure on the UE 
40 side, and which may provide the UTRAN 20u any nec- 
essary information for the UTRAN 20u to complete the 
procedure. The reconfiguration message and the response 
message may all carry optional information elements (lEs), 
which are fields of data that hold ancillary information. In 
addition to these reconfiguration procedures, there also 
exists a Cell Update procedure, which originates with a 
Cell Update message from the UE 40 and which is re- 
sponded to by the UTRAN 20u. The Cell Update procedure 
is used by the UE 40 to indicate a change of cell location 
(i.e., Node B 24), of connection state 82, 83, 84, 85, and 
is also used to indicate radio link (RL) failures and RLC un- 
recoverable errors. An RL failure is a connection failure 
that occurs in the physical layer, i.e., in layer 1 60. An RLC 
unrecoverable error occurs in the RLC layer 72, and may 
have many causes. 
[0010] For AM connections, when a sender RLC entity 76 detects 
one of the following situations, it shall senda RESET PDU 
to its peer RLC entity 76 to reset these two RLC peer enti- 



ties 76: 

[001 1] i)"No_Discard after MaxDAT number of retransmissions" 
is configured and VT(DAT) equals the value MaxDAT (see 
subclause 9.7.3.4 of TS 25.322); 

[0012] 2)VT(MRW) equals the value MaxMRW; 

[00 1 3] 3)A STATUS PDU including "erroneous Sequence Number" 

is received (see clause 10 of TS 25.322); 
[0014] _ stop transmitting any AMD PDU or STATUS PDU; 

[0015] -increment VT(RST) by 1; 

[0016] -if VT(RST) = MaxRST: 

[0017] _the Sender may submit to the lower layer a RESET PDU; 

[0018] -perform the actions specified in subclause 11.4.4a of TS 
25.322. 

[0019] _e| se (if VT(RST) < MaxRST): 

[0020] -submit a RESET PDU to the lower layer; 

[0021] _start the timer Timer.RST. 

[0022] please refer to subclause 11.4 of the above-indicated 

3GPP specification TS 25.322 for more details.When the 
maximum number of attempts to send a RESET PDU is 
reached, the sender RLC entity 76 shall terminate the on- 



going RLC RESET procedure and indicate an unrecoverable 
error to the upper layer (RRC layer 80).Whenthe RRC layer 
80 receives the indicated unrecoverable error from the AM 
RLC entity 76, the UE 40 shall perform a Cell Update pro- 
cedure using the cause "RLC unrecoverable error", i.e. the 
UE 40 shall send a CELL UPDATE message with an IE 
"AM.RLC error indication (RB2, RB3 or RB4)" or "AM.RLC 
error indication (RB>4)" set to "TRUE" to indicate the RLC 
unrecoverable errorhasoccurred in control plane 92 or in 
the user plane 94. Please refer to TS 25.331, subclause 
8.3.1 for more details of the Cell Update procedure, which 
is discussed briefly in the following. 

[0023] For an RLC unrecoverable error in the user plane 94, after 
reception of a CELL UPDATE/URA UPDATE message from 
UE 40, the UTRAN20u should optionally include the IE 
"RLC re-establish indicator (RB5 and upwards)" in the CELL 
UPDATE CONFIRM message to request an RLC re- 
establishment procedure in the UE 40, in which case the 
corresponding RLC entities 76 should also be re- 
established in UTRAN 20u. 

[0024] For an RLC unrecoverable error in the control plane 92, 
after reception of a CELL UPDATE/URA UPDATE message 
from UE 40, the UTRAN20u should optionally include the 



IE "RLC re-establish indicator (RB2, RB3 and RB4)" in the 
CELL UPDATE CONFIRM message to request an RLC re- 
establishment procedure in the UE 40, in which case the 
corresponding RLC entities 76 should also be re- 
established in UTRAN 20u, or initiate an RRC connection 
release procedure by transmitting an RRC CONNECTION 
RELEASE message on the downlink CCCH. 

[0025] |f an ri_ failure or an RLC unrecoverable errortakes place 
on a dedicated channel (i.e. the RRC layer 80 is in the 
CELL.DCH state 82), before sending a CELL UPDATE mes- 
sage, the UE 40 shouldperform radio access bearer (RAB) 
release steps, and then select a suitable cell 24. The RAB 
release steps release the RABs for which the associated 
timer T314/T3 15 is equal to zero.A RAB can comprise one 
or more RBs, but normally there is a one-to-one relation- 
ship between RABs and RBs. While performing the RLC re- 
establishment procedure, if eithertimer T314 orT315 ex- 
pires, the UE 40 should also release the RABs associated 
with the expired timer. Instructions as given by subclause 
8.3.1.2 of TS 25.331, as relates to the above, are provided 
below. All subclauses indicated in the steps below are 
from TS 25.331. 

[0026] when initiating the URA update or cell update procedure, 



the UE shall: 
[0027] i>stop timer T305; 

[0028] i>jf t he UE isin CELL.DCH state: 

[0029] 2> Perform RAB release steps; 

[0030] i >set t he variables PROTOCOL_ERROR_INDICATOR, FAIL- 
URE_INDICATOR, UNSUPPORTED.CONFIGURATION and IN- 
VALID.CONFIGURATION to FALSE; 

[0031] i >se t the variable CELL_UPDATE_STARTED to TRUE; 

[0032] i>jf the UE is not already in CELL.FACH state: 

[0033] 2 > move to CELL.FACH state; 

[0034] 2>select PRACH according to subclause 8.5.17; 

[0035] 2>select Secondary CCPCH according to subclause 8.5.19; 

[0036] 2>use the transport format set given in system informa- 
tion as specified in subclause 8.6.5.1. 
[0037] i>jf the UE performs cell re-selection: 

[0038] 2>clear the variable C.RNTI; and 

[0039] 2>stop using that C_RNTI just cleared from the variable 
C.RNTI in MAC. 

[0040] i>set CFN in relation to SFN of current cell according to 



subclause 8.5.15; 
[0041] i>j n case 0 f a ce || update procedure: 

[0042] 2>set the contents of the CELL UPDATE message accord- 
ing to subclause 8.3.1.3; 

[0043] 2>submit the CELL UPDATE message for transmission on 
the uplink CCCH. 

[0044] i>j n case 0 f a (jRA update procedure: 

[0045] 2>set the contents of the URA UPDATE message accord- 
ing to subclause 8.3.1.3; 

[0046] 2>submit the URA UPDATE message for transmission on 
the uplink CCCH. 

[0047] i >set counter V302 to 1; 

[0048] i>start timer T302 when the MAC layer indicates success 

or failure in transmitting the message. 
[0049] The prior art RAB release steps are given below. Again, 

subclauses mentioned in the steps below are from TS 

25.331. 

[0050] For the RAB release steps, the UE shall: 

[0051] 2>in the variable RB_TI M ER_I N D I C ATO R, set the IE "T314 
expired" and the IE "T315 expired" to FALSE; 

[0052] 2>if the stored values of the timer T314 and timer T315 
are both equal to zero; or 



[0053] 2>if the stored value of the timer T314 is equal to zero 
and there are no radio bearers associated with any radio 
access bearers for which in the variable ESTAB- 
LISHED.RABS the value of the IE "Re-establishment timer" 
is set to "useT315": 

[0054] 3>release all its radio resources; 

[0055] 3>indicate release (abort) of the established signalling 
connections (as stored in the variable ESTAB- 
LISHED_SIGNALLING_CONNECTIONS) and established radio 
access bearers (as stored in the variable ESTAB- 
LISHED.RABS) to upper layers; 

[0056] 3> c lear the variable ESTAB- 

LISHED_SIGNALLING_CONNECTIONS; 

[0057] 3> c lear the variable ESTABLISH ED.RABS; 

[0058] 3>enter idle mode; 

[0059] 3>perform other actions when entering idle mode from 

connected mode as specified in subclause 8.5.2; 
[0060] 3>and the procedure ends. 

[0061] 2>if the stored value of the timer T314 is equal to zero: 

[0062] 3>release all radio bearers, associated with any radio ac- 
cess bearers for which in the variable ESTABLISH ED_RABS 



the value of the IE "Re-establishment timer" is set to 
"useT314"; 

[0063] 3>jn the variable RELTIMERJNDICATOR set the IE "T314 

expired" to TRUE. 
[0064] 2>if the stored value of the timer T315 is equal to zero: 

[0065] 3>release all radio bearers associated with any radio ac- 
cess bearers for which in the variable ESTABLISH ED_RABS 
the value of the IE "Re-establishment timer" is set to 
"useT315"; 

[0066] 3 >in t he variable RB_TI M ER_I N D I C ATO R set the IE "T315 

expired" to TRUE. 
[0067] 2>if the stored value of the timer T314 is greater than 

zero: 

[0068] 3>jf there are radio bearers associated with any radio ac- 
cess bearers for which in the variable ESTABLISH ED_RABS 
the value of the IE "Re-establishment timer" is set to 
"useT314": 

[0069] 4>start timer T3 14. 

[0070] 3>jf there are no radio bearers associated with any radio 
access bearers for which in the variable ESTAB- 
LISHED.RABS the value of the IE "Re-establishment timer" 
is set to "useT314" or "useT315": 



[0° 71 ] 4>start timer T3 14. 

[0072] 2 >if the stored value of the timer T3 15 is greater than 
zero: 

[0073] 3>jf there are radio bearers associated with any radio ac- 
cess bearers for which in the variable ESTABLISH ED_RABS 
the value of the IE "Re-establishment timer" is set to 
"useT315": 

[0074] 4>start timer T3 15. 

[0075] 2>for the released radio bearer(s): 

[0076] 3>delete the information about the radio bearer from the 
variable ESTABLISH ED.RABS; 

[0077] 3>when all radio bearers belonging to the same radio ac- 
cess bearer have been released: 

[0078] 4>indicate local end release of the radio access bearer to 
upper layers using the CN domain identity together with 
the RAB identity stored in the variable ESTABLISH ED.RABS; 

[0079] 4>delete all information about the radio access bearer 
from the variable ESTABLISH ED.RABS. 

[0080] 2>select a suitable UTRA cell according to [4]; 

[0081] 2>set the variable ORDERED.RECONFIGURATION to FALSE. 
[0082] For example, if the stored value of the timer T3 14 is equal 



to zero and the stored value of the timer T3 15 is greater 
than zero, then the UE 40 shouldrelease locally all radio 
bearers 48 which are associated with any radio access 
bearers for which in the variable ESTABLISH ED.RABS the 
value of the IE "Re-establishment timer" is set to 
"useT314", andstart timer T315. If timer T315 expires, the 
UE 40 should also release locally all radio bearers 48 
which are associated with any radio access bearers for 
which in the variable ESTABLISH ED.RABS the value of the 
IE "Re-establishment timer" is set to "use T315", and enter 
idle mode 81. 

[0083] The prior art UE40, as detailed in TS 25.331, subclause 
8.3.1.2, treats the cases of both RL failure and RLC unre- 
coverable error while the RRC 80 is in theCELL_DCH state 
82 inthe same manner. That is, both error conditions 
while in the CELL_DCH state 82 will lead to the execution 
of the RAB release steps. However, RL failures and RLC 
unrecoverable errors have some essential differences. For 
example, an RLC unrecoverable error can be potentially 
"fixed" by returning to initial conditions by way of an RLC 
re-establishment procedure.An RL failure cannot, how- 
ever, be "fixed" by a re-establishment procedure, as it is 
fundamentally a physical problem with the radio connec- 



tion. Therefore, the usage of the timers T314 and T315 
for RLC unrecoverable errors(as performed by the RAB re- 
lease steps) on a dedicated channel is unwarranted, and 
may lead to some normally-functioning RABs (i.e. services 
or applications) being released before the RLC is re- 
established if the timers T314/T315 are shorter than the 
time required to perform the RLC re-establishment proce- 
dure. 

[0084] By wav 0 f example, consider the situation in which the UE 
40 is in the CELL.DCH state 82, and has U-plane 94 RABs 
6 to 10 that comprise RBs 48 6 to 10 with a one-to-one 
mapping. Furtherassume that the timer T314 is set to 
zero seconds, and that the timer T315 is set to 10 sec- 
onds, and that all RABs except RABs 6 and 7 are associ- 
ated with T314. If an RLC unrecoverable error occurs only 
on RB 6, the UE 40 sends a CELL UPDATE message with 
the IE "AM.RLC error indication (RB>4)" set to "TRUE" to 
the UTRAN 20u. The UTRAN 20u responds with a CELL 
UPDATE CONFIRM message that includes the IE "RLC re- 
establish indicator (RB5 and upwards)" to request a RLC 
re-establishment for all RABs 6 to 10 in the UE 40. The 
RABs 8,9 and 10 (i.e. RB 8,9 and 10) that are running cor- 
rectly will be released before re-establishment is com- 



pleted, since the timer T314 (at zero seconds) is shorter 
than the time required to perform the RLC re- 
establishment procedure. The malfunctioning RB 6 (i.e. 
RAB 6)is restored to operational order after performing 
the RLC re-establishment procedure, but the correctly 
functioning RBs 8,9 and 10 (i.e. RABs 8,9,10) are released 
before performing the RLC re-establishment proce- 
dure.The unnecessary release of correctly functioning 
RABs (i.e. services or applications) by the RAB release 
steps leads to areduction in the radio utilization capacity, 
and increases the services drop rate, which is a great in- 
convenience to the user of the UE 40. 
[0085] Finally, according to subclause 8.3.1.6 of TS 25.331, the 
UE 40 shall handle both the IE "RLC re-establish indicator 
(RB2, RB3 and RB4)" and IE "RLC re-establish indicator 
(RB5 and upwards)"if received in the CELL UPDATE CON- 
FIRM message. However, according to subclause 8.3.1.5 
of TS 25.331, the UTRAN 20u may only include the IE "RLC 
re-establish indicator (RB5 and upwards)" in the CELL UP- 
DATE CONFIRM message. Hence, the IE "RLC re-establish 
indicator (RB2, RB3 and RB4)"is actually a useless proce- 
dural indicator, as it is impossible to be included in the 
CELL UPDATE CONFIRM message by the UTRAN 20u. 



Summary of Invention 

[0086] it j S therefore a primary objective of this invention to pro- 
vide an improved method for handling an unrecoverable 
error on a dedicated channel so as to avoid the above- 
indicated problems. 

[0087] | n a preferred embodiment, the present invention dis- 
closes a method, and associated wireless device, for han- 
dling an unrecoverable error on a dedicated channel. 
Briefly, if it is determined that the wireless device is in the 
CELL_DCH state and that a layer one radio link failure has 
occurred, improved radio access bearer (RAB) release 
steps are performed to release radio bearers. However, if 
it is determined that the wireless device is in the 
CELL_DCH state and that layer one radio link failure has 
not occurred, the RAB release steps are not performed. 

[0088] Additionally, the present invention method explicitly per- 
mits the UTRAN to transmit a CELL UPDATE CONFIRM 
message to the UE that contains the information element 
(IE) "RLC re-establish indicator (RB2, RB3 and RB4)". 

[0089] it is an advantage of the present invention that by per- 
forming the RAB release steps only when a layer one radio 
link failure is detected on the dedicated channel, unnec- 
essary releasing of RABs is avoided, and thus theunneces- 



sary dropping of services if avoided. By avoiding use of 
the timer T314 and T315 for RLC unrecoverable errors, 
the UE is ensured to be provided enough time to re- 
establish the RLC connections, and thus restore services 
with dropping the RABs. 

[0090] it is yet another advantage of the present invention that 
the UTRAN may explicitly include the IE "RLC re-establish 
indicator (RB2, RB3 and RB4)" in the CELL UPDATE CON- 
FIRM message sent to the UE, and hence give relevance to 
the IE "RLC re-establish indicator (RB2, RB3 and RB4)" ini- 
tially transmitted by the UE to the UTRAN. 

[0091] These and other objectives of the present invention will no 
doubt become obvious to those of ordinary skill in the art 
after reading the following detailed description of the pre- 
ferred embodiment, which is illustrated in the various fig- 
ures and drawings. 
Brief Description of Drawings 

[0092] pig.l is a simple block diagram of a wireless communica- 
tions system. 

[0093] pig. 2 is a simple block diagram of a UMTS radio interface 

protocol architecture. 
[0094] pig. 3 is a state diagram of a Radio Resource Control (RRC) 

RRC layer shown in Fig. 2. 



[0095] pig. 4 is a block diagram of a wireless device according to 
the present invention. 

[0096] pig. 5 is a flowchart for determining how the UE of Fig. 4 

performs a cell or URA update procedure according to the 
present invention. 

[0097] Fig. 6 is a flowchart of a present invention procedure that 
the UTRAN of Fig.l executes after receiving a CELL UP- 
DATE or URA UPDATE message. 
Detailed Description 

[0098] | n the following description, user equipment (UE) is a 
wireless communications device, and may be a mobile 
telephone, a handheld transceiver, a personal data assis- 
tant (PDA), a computer, or any other device that requires a 
wireless exchange of data. It is assumed that this wireless 
exchange of data conforms to 3CPP-specified protocols. 

[0099] please refer to Fig. 4. Fig. 4 is a block diagram of a user 

equipment (UE) 100 according to the present invention. In 
most respects, the present invention UE 100 is identical to 
a UE of the prior art. The UE 100 includes devices for ac- 
cepting input and providing output, such as a keypad 102 
and a liquid crystal display (LCD) 104, respectively. A 
transceiver 108 is capable of receiving wireless signals 
and providing corresponding data to a control circuit 106, 



and can also wirelessly transmit data received from the 
control circuit 106. The transceiver 108 is thus part of the 
3GPP layer 1 stack 60 of the present invention communi- 
cations protocol. The control circuitry 106 is responsible 
for controlling the operations of the UE 100, and is used 
to implement the layer 2 and layer 3 stacks of the 3GPP 
communications protocol; in particular, for implementing 
the RRC layer 80, with suitable modifications to accom- 
modate the present invention improvements. To this end, 
the control circuitry 106 includes a central processing unit 
(CPU) 106c in electrical communication with memory 
106m, an arrangement familiar to those in the art of wire- 
less communication devices. The memory 106m holds 
program code 107 that is used to implement the layer 2 
and layer 3 stacks of the present invention communica- 
tions protocol. With respect to a UE of the prior art, the 
present invention UE 100 has modifications to the pro- 
gram code 107 to implement the present invention 
method, providing modifications to the program code 107 
that relate to the RRC layer 80 so as to implement the 
present invention improvements. These modifications 
should be well within the means of one reasonably skilled 
in the art after reading the following detailed description 



of the preferred embodiment. 
[0100] when an RLC unrecoverable error occurs (as detected by 
the RLC layer 72) on a dedicated channel (i.e. the RRC 
layer 80 is in the CELL.DCH state 82), the UE 100 does not 
check to see if timer T314 109a or timer T315 109b is 
zero to release the associated RABs.That is, the RAB re- 
lease steps are not called in response to an RLC unrecov- 
erable error while the UE 100 is in the CELL_DCH state 82. 
Hence, the timers T314 109a and T315 109b are only 
used for RL failure (as detected by the layer 1 interface 60 
of the transceiver 108), and are not used for RLC unrecov- 
erable errors (as detected by the RLC layer 72) on a dedi- 
cated channel. 

[0101] when a cell update procedure is to be performed, the 
present invention further alters the conditions under 
which the RAB release steps are performed. The following 
details the improved steps of the present invention 
method (as implemented by program code 107) that de- 
termine how the UE 100 performs a cell update procedure 
or URA update procedure. 

[0102] Referring to the flowchart 200 of Fig. 5, when initiating the 
URA update or cell update procedure, the UE shall: 

[° 1 03] l>stop timer T305; 



[0104] i>jf the UE isin CELL.DCH state; and 

[0105] i> jf the cause that triggers this procedure is due to "ra- 
dio link failure": 
[0106] 2>perform improved RAB release steps; 

[0107] i >set the variables PROTOCOL_ERROR_INDICATOR, FAIL- 
UREJNDICATOR, UNSUPPORTED.CONFIGURATION and IN- 
VALID.CONFIGURATION to FALSE; 

[0108] i >set the variable CELL_UPDATE_STARTED to TRUE; 

[0109] i>jf the UE is not already in CELL.FACH state: 

[0110] 2 > move to CELL.FACH state; 

[0111] 2>select PRACH according to subclause 8.5.17; 

[0112] 2>select Secondary CCPCH according to subclause 8.5.19; 

[0113] 2>use the transport format set given in system informa- 
tion as specified in subclause 8.6.5.1. 
[0114] l >jf the UE performs cell re-selection: 

[0115] 2>clear the variable C.RNTI; and 

[0116] 2>stop using that C_RNTI just cleared from the variable 
C.RNTI in MAC. 

[0117] i>set CFN in relation to SFN of current cell according to 
subclause 8.5.15; 



[0118] i>in case of a cell update procedure: 

[0119] 2>set the contents of the CELL UPDATE message accord- 
ing to subclause 8.3.1.3; 

[0120] 2>submit the CELL UPDATE message for transmission on 
the uplink CCCH. 

[0121] i>j n case 0 f a URA update procedure: 

[0122] 2>set the contents of the URA UPDATE message accord- 
ing to subclause 8.3.1.3; 

[0123] 2>submit the URA UPDATE message for transmission on 
the uplink CCCH. 

[0124] i >set counter V302 to 1; 

[0125] i>start timer T302 when the MAC layer indicates success 
or failure in transmitting the message. 

[0126] Subclauses mentioned in the steps above are identical to 
those in the prior art, and refer to TS 25.331. Hence, for 
the sake of brevity, the details of those steps contained 
within the above-mentioned subclauses is omitted. Note 
that the present invention cell update/URA update proce- 
dural steps now ensure that the RAB release steps are 
performed only if (1) the UE 100 is in the CELL.DCH state 
82; and (2) the cause that triggers the cell update/URA 
update procedure is due to "radio link failure". Hence, 



with the present invention procedure, as implemented by 
the program code 107, only a "radio link failure" type er- 
ror can cause the execution of the RAB release steps. In 
particular, then, an "RLC unrecoverable error" type cause 
for performing the present invention cell update/URA up- 
date procedure cannot and does not lead to the execution 
of the RAB release steps. 

[0127] To ensure that the IE "RLC re-establish indicator (RB2, RB3 
and RB4)" is functionally relevant and useful procedural 
indicator, the present invention augments the procedure 
steps taken by the UTRAN 20u when the UTRAN 20u re- 
ceives a CELL UPDATE/URA UPDATE message. The steps 
are detailed below and illustrated in the flowchart 300 of 
Fig. 6, and correspond to the prior art steps detailed in TS 
25.331 subclause 8.3.1.5. 

[0128] when the UTRAN receives a CELL UPDATE/URA UPDATE 
message, the UTRAN should: 

[0129] i>j n case the procedure was triggered by reception of a 
CELL UPDATE: 

[0130] 2>if SRNS relocation was performed: 

[0 1 3 1 ] 3>transmit a CELL UPDATE CONFIRM message on the 

downlink DCCH. 
[0132] 2>otherwise: 



[0133] 3>update the START value for each CN domain as main- 
tained in UTRAN with "START" in the IE "START list" for the 
CN domain as indicated by "CN domain identity" in the IE 
"START list"; 

[0134] 3>jf this procedure was triggered while the UE was not in 
CELL_DCH state, then for each CN domain as indicated by 
"CN domain identity" in the IE "START list": 

[0135] 4>set the 20 MSB of the MAC-d HFN with the correspond- 
ing START value in the IE "START list"; 

[0136] 4>set the remaining LSB of the MAC-d HFN to zero. 

[° 137 ] 3>transmit a CELL UPDATE CONFIRM message on the 

downlink DCCH or optionally on the CCCH but only if ci- 
phering is not required; and 

[0138] 3>optionally include the IE "RLC re-establish indicator 

(RB2, RB3 and RB4)" and the IE "RLC re-establish indicator 
(RB5 and upwards)" to request a RLC re-establishment in 
the UE, in which case the corresponding RLC entities 
should also be re-established in UTRAN; or 

[0139] i>j n case the procedure was triggered by reception of a 
URA UPDATE: 

[0140] 2>if SRNS relocation was performed: 

[0141] 3>transmit a URA UPDATE CONFIRM message on the 



downlink DCCH. 
[0 142 ] 2>otherwise: 

[° 143 ] 3>transmit a URA UPDATE CONFIRM message on the 
downlink CCCH or DCCH. 

[O 144 ] 2>include the IE "URA identity" in the URA UPDATE CON- 
FIRM message in a cell where multiple URA identifiers are 
broadcast; or 

[0145] i>initiate an RRC connection release procedure by trans- 
mitting an RRC CONNECTION RELEASE message on the 
downlink CCCH. In particular UTRAN should: 

[0146] 2>if the CELL UPDATE message was sent because of an 
unrecoverable error in RB2, RB3 or RB4: 

[0147] 3 > initiate an RRC connection release procedure by trans- 
mitting an RRC CONNECTION RELEASE message on the 
downlink CCCH. 

[° 14 8] The UTRAN may transmit several CELL UPDATE CONFIRM/ 
URA UPDATE CONFIRM messages to increase the probabil- 
ity of proper reception of the message by the UE. In such a 
case, the RRC SN for these repeated messages should be 
the same. 

[0149] with regard to the steps above, it should be noted that the 
present invention steps enable the UTRAN to optionally 
include the IE "RLC re-establish indicator (RB2, RB3 and 



RB4)" and/or the IE "RLC re-establish indicator (RB5 and 
upwards)" to request a RLC re-establishment in the UE. In 
contrast, the prior art permitted only the IE "RLC re- 
establish indicator (RB5 and upwards)". 

[0150] | n contrast to the prior art, the present invention prevents 
the RAB release steps from being performed when an RLC 
unrecoverable error is detected while the UE is in the 
CELL_DCH state. Additionally, UTRAN may explicitly in- 
clude the IE "RLC re-establish indicator (RB2, RB3 and 
RB4)" in the CELL UPDATE CONFIRM message sent to the 
UE, and hence give relevance to the IE "RLC re-establish 
indicator (RB2, RB3 and RB4)" initially transmitted by the 
UE to the UTRAN in the CELL UPDATE message. 

[0151] Those skilled in the art will readily observe that numerous 
modifications and alterations of the device may be made 
while retaining the teachings of the invention. Accord- 
ingly, the above disclosure should be construed as limited 
only by the metes and bounds of the appended claims. 



